In a network system in which two or more computers are connected to one another via a network, it is frequently necessary, for example in the case of particularly time-consuming computation tasks to move the computation task to two or more other computers owing to the limited computation power of the individual computers in the network. Lack of memory capacities in the individual computers or a centrally located database may also necessitate network access. In this case, access and executive rights of the computers and devices in the network which are intended to be accessed must be taken into account in order, for example, to move the computation task.
A user is normally registered with a first computer that is connected to the network. If a time-consuming computation task is being carried out on this first computer, an application which is running on the first computer attempts to distribute the computation task between two or more second computers which are connected to the first computer via the network. For this purpose, the application which is running on the first computer sends appropriate orders via the network to the second computer, or to each of the second computers.
In order to make it possible to process the orders, it is normally necessary for the second computer or computers first of all to check on the basis of the access and/or executive rights of the user of the first computer whether that user is authorized for access to the second computer or computers. Various approaches are known for this purpose:
According to a first approach, the user is known and registered both with the first and with the second computer or computers. In this case, each computer can itself check the access and/or executive rights of the registered user.
In a second approach, the access and/or executive rights are managed centrally by a central computer in the network for the entire network, as a result of which the user of the first computer is known throughout the entire network via the central computer.
This approach is thus dependent on a configured computer network with a central computer for carrying out the checking of the access and/or executive rights.
A third already known solution approach is known by the name “Corba Call Chain” and will be described in more detail in the following text with reference to FIG. 4.
In the example shown in FIG. 4, a user wishes to use a user request 50 to access a target object 48 which is contained in a sub-domain 45 of a domain 40.
The user request 50 is first of all checked by an access controller 41 in the domain 40 to determine whether the user is authorized for access to objects 42, 43, 44 or sub-domain 45 which are contained in the domain 40.
If the user is authorized for access, the access controller 41 allows access to the domain 40. Otherwise, the access controller 41 for the domain 40 rejects access by the user, and rejects the passing on of the user request 50.
If the access controller 41 for the domain 40 allows access by the user, the user request 50 is passed on to the sub-domain 45 contained in the domain 40.
The user request 50 is then checked by an access controller 46 for the sub-domain 45 to determine whether the user is also authorized for access to objects 47, 48, 49 and sub-sub-domain (which are not shown in FIG. 4) contained in the sub-domain 45.
If the user is authorized for access to objects 47, 48, 49 which are contained in the sub-domain 45, then the access controller 46 for the sub-domain 45 allows access, and the user can access the target object 48, which is contained in the sub-domain 45, via the user request 50. Otherwise, the access controller 46 rejects access by that user to objects 47, 48, 49 which are contained in the sub-domain 45.
The Corba Call Chain is thus based on a chain of functional procedures as far as a target object. In order to check the access authorization, it is necessary to pass on the identity of the user, the identity of an access controller that is connected to the chain, or both the identity of the user and the identity of the access controller that is located in the chain, together with the user request. Transmission of this information is the only way to allow checking of the access authorization by the access controllers which are located in the chain.
As can clearly be seen from FIG. 4, the checking of the access authorization for the Corba Call Chain is always physically carried out within the chain at the location of the respective processing. The checking of the access authorization is thus carried out hierarchically before approval of access to a domain or sub-domain and by that computer to which access is intended.
U.S. Pat. No. 5,315,657 describes the determination of access rights to system resources in distributed network systems. An Access Control List (ACL) is disclosed there, on the basis of which the access rights of users who start orders are determined, to be precise on the basis of those rights which are recognized for the respective user. A personal key (private key) is used to identify the respective user; a further session key may additionally optionally be used, which identifies the respective session of a user.
The solution approaches which are already known from the prior art have various disadvantages, some of which are serious.
Registration of a user with all of the computers in a network which may possibly be accessed is associated with unacceptable complexity. Furthermore, multiple registration by the user results in the problem that the computers with which the user is registered cannot all be supervised at the same time, so that an unauthorized third party can easily gain unauthorized access to the network via an unsupervised registered computer. Furthermore, multiple registration of a user results in a very high risk of the user forgetting to log off from all the computers again after the task ends.
Central access control via a central computer for the network in turn involves the disadvantage that this is dependent on a network with a central computer, and the central computer as well as the computers that are connected in the network must be set up for central access control. In the event of a malfunction of the central computer, it may be impossible for any of the users to access the network. Furthermore, access authorizations are normally allocated by a system administrator on the central computer, so that this system is very inflexible.
The Corba Call Chain once again has the disadvantage that the identity of the client or at least the identity of the access controllers which are located in the chain must in each case be transferred together with the user request in order to check the access authorization. In consequence, the method is highly susceptible to manipulations since the information which is attached to the user request can easily be eavesdropped on and misused. Furthermore, the individual access controllers in the chain must know the access rights and/or executive rights which are associated with the identity of the respective user and with the access controllers which are located in the chain, so that it is highly complex and tedious to set up a Corba Call Chain. The Corba Call Chain is therefore very inflexible.